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ABSTRACT 

Many operability problems exist at the three Deep 
Space Communications Complexes (DSCC’s) of the 
Deep Space Network (DSN). Four years ago, the 
position of DSN Operability Engineer was created 
to provide the opportunity for someone to take a 
system-level approach to solving these problems. 
Since that time, a process has been developed for 
establishing communication between operations 
personnel and development engineers and for 
enforcing user interface standards in software 
designed for the DSCC’s. Plans are for the 
participation of operations personnel in the product 
life-cycle to expand in the future. 
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1. BACKGROUND 

The Deep Space Network (DSN) is a space-to- 
ground telecommunications network operated by the 
Jet Propulsion Laboratory (JPL) for NASA. It is 
used for supporting deep-space missions, high 
Earth-orbiting flight projects, and radio astronomy 
experiments. It consists of multiple facilities, 
including a central Network Operations Control 
Center (NOCC) at JPL, the Central Communica- 
tions Terminal (CCT) at JPL, and three Deep 
Space Communications Complexes (DSCC’s), 
located in Goldstone, California; Madrid, Spain; 
and Canberra, Australia. 

There are many people within the JPL community 
with a legitimate interest in the requirements, 
design, and implementation of DSN subsystems. 
Since JPL has a matrix management organizational 
structure consisting of program offices and 
technical divisions, the responsibilities for different 
phases of the product life-cycle cut across 
organizational boundaries. Also, since DSN 
operations facilities are worldwide, there are 


several different organizations in different physical 
locations that are part of the operations structure. 
Communication problems can develop as a result of 
this distribution of personnel across organizational 
boundaries and over many physical locations. 

Four years ago, the DSN created the position of the 
DSN Operability Engineer, with the charter to ease 
the operational complexity of the network. This 
position requires someone with a background in 
both software engineering and human factors 
engineering, as well as considerable management 
experience. 

This paper describes the process that has taken 
place since I was appointed to the position of the 
DSN Operability Engineer. 

2. OPERATOR POINT-OF-VIEW 

One of the first steps I took after receiving the new 
assignment was to visit the DSCC sites in 
California, Spain, and Australia. This provided me 
an opportunity to meet operations personnel and 
learn about their concerns and problems. I spent 
considerable time observing day-to-day operations 
and talking with operators. Other JPL engineers 
had done this, but as one DSCC operator later 
commented, "That was the first time that someone 
actually wrote down the comments that we made. " 
In general, operators felt that developers never 
listened to them and never incorporated solutions to 
their complaints in new software releases. It was 
also the operators’ perception that the DSN is a 
collection of independent subsystems rather than a 
cohesive system. 

Actually, developers at JPL were very aware that 
operators were not happy, but did not always 
understand the specific areas of concern or have the 
expertise to solve the problems. Even when 
problems were understood, no one before had ever 
had the responsibility to collect the comments and 
provide a system-level approach to responding to 
them. That was the service that I could perform. 
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3. THE PROBLEM DEFINED 


4. COMMUNICATION 


Many operability problems were discovered during 
these discussions with operators. As an example, 
at the DSCC’s there are over 1500 commands that 
the operator must use to control the system. Since 
the current Monitor and Control subsystem only 
provides a command-line interface, the operator 
must memorize the 1500 commands. Many of the 
commands, particularly in the area of subsystem 
configuration, are not necessary, since the 
appropriate information could be accessed by the 
software from files. Another problem is that 
similar functions in different subsystems are often 
initiated by different commands: for example, the 
command to perform subsystem configuration is 
variously CNF, CONF, or CFG. These problems 
have developed because within each operational site 
are numerous subsystems that were designed, 
developed, and upgraded at different points in time. 
Traditionally, there has been little communication 
among the engineers responsible for developing the 
various subsystems; thus, a set of subsystems has 
been created that is not always cohesive in the 
operational environment. 

There were many other operability problems. 

Owing to insufficient automation, information was 
frequently communicated on pieces of paper, thus 
requiring extensive key-in’s on the part of the 
operator. The displays used for monitoring the 
status of the DSN were far too crowded, and the 
out-of-date technology prohibited true hierarchies of 
displays. Log displays were congested with too 
many messages, thus causing important messages to 
be lost in the heavy flow of traffic. The monitor 
and control equipment was antiquated, and monitors 
were poorly placed from an ergonomic point of 
view. Some of the monitors were so old that the 
clarity of the display presented was very poor, 
causing difficulty in reading the data. 

Another operability problem was the lack of com- 
mon displays and acronyms among the operational 
facilities: the DSCC’s, the NOCC, and the CCT. 

The operators at the facilities are constantly in 
voice communication, and difficulties arise because 
of a lack of standards in presenting information 
(e.g., the unit of measure for a particular data 
item). This problem extends beyond the DSN 
boundaries to the DSN interface with the Multi- 
mission Ground Data System (MGDS) in the JPL 
Space Flight Operations Facility, from which an- 
other version of the data may be given to an operator. 


Three years ago, several major tasks were starting 
up that were designed to enhance the DSCC’s with 
the delivery of many upgraded subsystems. One 
goal of these tasks was to improve the operability 
of these subsystems, although many of the oper- 
ability problems cannot be resolved until a new 
Monitor and Control subsystem is provided. 
Although the Monitor and Control subsystem was 
not scheduled for replacement, the operability goal 
was set to eliminate as many problems as possible. 

One major goal I had was to increase the level of 
communication between the operations personnel at 
the DSCC’s and the development engineers at JPL. 
At that time, no formal mechanism existed for 
communication, and any communication that 
occurred did so on an ad hoc basis. Attempts at 
effective communication were made by using such 
techniques as videoconferences, overseas phone 
calls, and operability meetings at JPL. Pivotal in 
the success that was achieved was the appointment 
of a person at each DSCC to serve as the 
Operability Interface Engineer for that DSCC. 

That person is responsible for talking with the 
various DSCC crews and compiling the operator 
input into one integrated viewpoint for that DSCC. 

The forum for communication that has proven to be 
the most successful is to send information electron- 
ically and then to have follow-up telephone con- 
ferences as needed. The major problem with this 
method of communication is one of time con- 
straints. The personnel at the DSCC’s are very 
busy and cannot always read and critique a docu- 
ment immediately upon receiving it. Of course, the 
JPL development engineers generally need to have 
answers very quickly if they are to remain on 
schedule. We have not solved the resulting conflict 
effectively. 

Early on, videoconferences were tried, but these 
did not prove to be very successful forums for 
communication. The data rates of the video- 
conference system we used were so low that all 
viewgraphs had to be sent ahead of time. Since it 
took several minutes to paint a screen, sending 
anything in real time was not practical. Although 
time zone differences exist, from California to 
Australia to Spain, these differences were not a 
major problem since the involved people showed a 
willingness to come in during the night, if 
necessary, in order to participate. 
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Face-to-face communication with representatives 
from the DSCC’s has been possible because, as 
part of the tasks, each DSCC provides one person 
to work at JPL as part of an Independent Test 
Group (ITG). Operability meetings have been held 
with the ITG members and JPL development 
engineers participating. These groups have been 
very useful, but are limited in their decision-making 
ability in that the ITG member is not always the 
Operability Interface Engineer for that DSCC and 
thus may not be able to speak officially for the 
DSCC. 

In alternate years, the Operability Interface 
Engineers from the DSCC’s come to Pasadena for 
an Operability /Monitor and Control workshop that 
generally lasts for one week. The topics discussed 
are quite varied, from anomalies in the current 
subsystems to creative thinking concerning the 
future. These meetings have been very useful in 
providing an opportunity to exchange ideas and 
make decisions. 

5. DOCUMENTATION 

Another opportunity to improve operability was to 
enforce the rule to design and document the user 
interface early in the design process, rather than to 
allow the development engineers to design the user 
interface during implementation and to document 
whatever user interface was delivered. This was 
accomplished by holding a series of rigorous 
reviews of the software operators manuals with the 
participation of operations personnel during the 
time frame of the high-level design. The challenge 
here is to follow through and make sure that the 
development team does not change the interface 
during implementation. The ITG team members 
test for this as part of their function. 

Although user interface standards already existed in 
the DSN, the standards had never been successfully 
enforced. Enforcement has now been accomplished 
via the early review of the software operators 
manuals by operations personnel and the signature 
approval of the manuals by the Operability 
Engineer. The early review of the manuals has 
also increased the usability of the subsystems. 

To improve the usability of documentation for 
operations personnel, a new format for the software 
operators manuals was developed with the 
participation of the users. The new format is 
designed to present an efficient, real-time 


document, with certain sections designed for quick 
reference and other sections for more detailed 
study. A section on messages and suggested 
operator responses is included. The manuals are in 
a landscape format, so that a picture of a display 
and the written description of that display are 
available on back-to-front pages for easy viewing. 
Since work space at the operator consoles is 
limited, the manuals are currently in the process of 
being printed on smaller (8.5 inches by 5.5 inches) 
paper. They will be put in binders for ease of use. 
Also, a quick-reference manual containing 
information on all subsystems is being developed. 

6. SUCCESSES AND FAILURES 

One evidence of success is that development 
engineers are more conscious of operability issues 
these days. They hold meetings on the issues, ask 
questions, and find they are rewarded by talking 
with operations personnel. In general, there is a 
heightened awareness of operability issues. The 
following is a description of some of the specific 
successes and failures. 

There is far more communication these days 
between operations personnel and JPL engineers. 
Currently, a proposal is being developed that will 
formalize the methodology for the participation of 
operations personnel in the entire development life- 
cycle of all subsystems in the DSN, from 
requirements through implementation. We have 
evolved from almost no participation four years 
ago, to participation in the design phase, to 
participation in all phases. 

An operability module has been written for the 
DSN baseline requirements document that will 
govern all new subsystems. A preliminary 
requirements document for a new Monitor and 
Control subsystem at the DSCC’s is being 
reviewed. This document contains many 
requirements designed to remove operational 
complexity from the DSCC’s. 

Other successes include a set of standard commands 
and display acronyms, online help screens, and 
standard system-administration procedures. New 
subsystems provide for configuration with one 
command by having the software access parameters 
from files sent electronically from JPL, rather than 
requiring the operator always to enter the 
parameters manually. Also, operations personnel 
were allowed to participate early enough in the 
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design process that frequently their input was 
incorporated into the final products. When the 
design could not accommodate their input, at least 
the operators were able to understand the reasons 
and learn the period of time when the product 
would not have the feature(s) they wanted. 

The new subsystems use a common software 
program set providing standardization of many user 
interface features. Since the code is being written 
by one group, standardization is assured. 

In the Monitor and Control subsystem, operations 
personnel have contributed very instrumentally to 
the requirements for the various releases. Opera- 
tors had long been unhappy with the position of one 
of the four monitors found on each operator work- 
station. Discussions were held with the DSCC’s, 
and all new workstations have the monitor posi- 
tioned in a more ergonomically favorable location. 
Also, the worst monitors have been replaced with 
newer ones to improve readability. 

The major failure, so far, involved one particular 
subsystem. Even though the subsystem develop- 
ment team talked extensively with the personnel at 
one DSCC, they did not write a software operator 
manual early in the design process and did not 
implement features agreed to in the meetings. 

Very few operability items were incorporated in the 
first release of that subsystem, but subsequent 
releases are addressing the items that were asked 
for by the DSCC personnel. 

7. FUTURE 

There are still major improvements to be made. 


The following items are the ones to be implemented 
over the next couple of years. 

In order for operations personnel to evaluate 
proposed designs, an operations scenario needs to 
be developed for each subsystem and activity, 
starting at requirements generation and being 
further refined at each stage in the development 
life-cycle. A standard for this operations scenario 
needs to be developed. 

A more extensive data base of acronyms and units 
of measure needs to be developed to be used 
throughout the DSN— from the DSCC’s, to the 
CCT, to the NOCC. Common displays need to be 
developed for utilization by all DSN facilities and 
by the Multimission Ground Data System in the 
JPL Space Flight Operations Facility. 

New standards must be developed for graphical 
user interfaces, and a user interface presentation 
must be developed that allows the DSN subsystems 
to be viewed as a system by the operator, and not 
just as an ad hoc collection of program sets. 

With all of these changes, the DSN will be able to 
continue doing an excellent job of tracking and data 
acquisition, and the operational environment will 
continue to be improved for the DSN operators. 
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